[NCLUG] programming question

[mike cullerton]

on 6/30/01 4:30 PM, Gary Rogers at garyr at dmin.net wrote:

> Are you sure that your time is spent in the application? Here's what I'm

this is a theoretical question. i'm wondering, is there a difference, in
general, programmatically speaking, between having one large object, two
disjoint objects or an object that extends another object.

> getting at: With a web page there are many variables that go into to
> download speed. Identifying where the slow down is is part of tuning the
> pages for maximum speed. In your case I'd say you're probably right, it will
> be a SQL issue. However, you may be seeing DNS lookups taking time, or
> initial download, especially if you're behind a firewall that supports
> Stateful packet inspection.

i didn't mean to suggest there was a current problem. the code wasn't even
written when i asked the question. (it is currently written as two disjoint
classes)

there is no current problem. the sql issue was just something i learned from
a previous project. mentioning it probably confused the situation. sorry.
currently, everything (already written) works fine. it's all contained on
one ethernet, running on an underused server, with local dns. rather than
trying to solve a particular problem, i'm trying to learn about oop
programming in general.

> 
> The best page download timer that I've used was with Keynote systems, but
> that's probably not an option. Find a page timer that splites things down
> into DNS lookup, initial TCP connection, Page download. Then you're sure
> that your page is the bottle neck.

Keynote, huh?! that's starting a holy war :)

> 
> Beyond that I'm not sure what tools MySQL gives you to time queries. I've
> worked with Oracle DBA's that could find out how long my quesies were
> taking. Also, WebLogic was good about telling my how long pages were
> connected to the database. Can PHP time your queries for you? The question
> you're looking to answer here is this: Are my queries taking long because of
> the Database, or because of some code manipulation I'm doing with the
> returned code? I want to say that as much code manipulation you can do
> inside the database the better, but that's only because I'm used to beefy
> database machines that handle cpu intensive joins better than ripping
> returned data with perl on the Webservers, or in your case PHP.

again, there is no current problem. as i mentioned in my first post, the sql
issue was solved by adding an additional index to a table defintion.

as for php timing queries, one could always check the time before issuing a
query and again when a result is received, and then comparing the times. if
using the PEAR DB modules, the result handler contains all the result info i
believe.

if i do end up having a bottleneck somewhere, i'm betting on the fact that
the server is an old dual pentium 166 :)

> 
> Anyway, just don't assume that it's your code is all I'm saying. You may
> have to transfer where you're doing the work to get better performance from
> a web application.

the question only applies to the code. 'other things equal' so to speak

thanks,
mike

> 
> Gary Rogers
> (former) Web SysAdmin ;)
> 
> ----- Original Message -----
> From: "Evelyn Mitchell" <efm at tummy.com>
> To: <nclug at nclug.org>
> Sent: Saturday, June 30, 2001 3:08 PM
> Subject: Re: [NCLUG] programming question
> 
> 
>> On Sat, Jun 30, 2001 at 01:40:15PM -0600, mike cullerton wrote:
>>>> It helps to understand what resources you're trying to conserve.
>>> 
>>> i hadn't really thought about it specifically, but now that you ask, i'd
> say
>>> processing or maybe even latency. this is a web based program written in
>>> php. in an earlier prototype of this app, i had one page that took a
> long
>>> time to load. that turned out to be a mysql problem. i fixed it by
> adding a
>>> new index.
>>> 
>>> so, would any particular approach add an extra amount of processing or
>>> latency?
>> 
>> The only way to discover that is to profile the three different
>> approaches and see which one takes more processing or have higher latency.
>> 
>> Evelyn
>> 
>> _______________________________________________
>> NCLUG mailing list
>> NCLUG at nclug.org
>> http://www.nclug.org/mailman/listinfo/nclug
>> 
> 
> _______________________________________________
> NCLUG mailing list
> NCLUG at nclug.org
> http://www.nclug.org/mailman/listinfo/nclug
> 


 -- mike cullerton