[webstack-discuss] FW: PHP with Apache in build 77

[matt.ingenth...@sun.com]

Jyri Virkki wrote:
> UNIX admin wrote:
>   
>> For my part, I would very much like to see php be available as /usr/bin/php.
>>
>> What is the final consensus on this matter?
>> 
>
> No formal consensus, but I filed an RFE to track the change. When
> someone gets to making the code changes and posts the code review,
> it'll probably be approved. It should get recorded in a relevant ARC
> case as well, though I don't really expect opposition there either.
> There's a lot of process for seemingly simple changes, which is why
> the answer to "final consensus" isn't so straighforward... But I
> wouldn't expect adding this to be a problem, just a matter of doing it.
>
>
>   
>> In my experience, for PHP, making a distinction between "php4" and
>> "php5" is enough.
>> 
>
> Good to hear.
>
>   
>> With this in mind, I propose that the packages be renamed before
>> Nevada is solidified into the next release of Solaris. Current
>> naming is "SUNWphp520", whereas in my experience "SUNWphp5r" and
>> "SUNWphp5u" would have been just fine (and elegant).
>> 
>
> At the very least I'd like to see it versioned at the "5.2" (5.2.*)
> level, but if versioning it as 5 (5.*.*) is possible, that would be
> ideal.  I didn't use PHP prior to php5 so I can't comment on enough of
> its compatibility history but I'd like to hear from others here who've
> used it long enough so we can gather enough data to go one way or the
> other.
>   

Of course, the challenge here is that if we did drop the micro, or even 
the minor and there was an incompatible change significant enough we'd 
be breaking other people's code, we would find it harder to deliver the 
micro release through a patch though.  Other options would be to to fork 
or reintroduce the more explicitly versioned path.  The point here is 
there is no control over when there is an incompatibility introduced.

Perhaps there's a good middle ground here somewhere?  I read up on a 
bunch of the ARC cases when Stefan originally started the PHP update, 
and there was some discussion of how Java does things now.  It seemed no 
one was really happy with the symlinks in /usr/jdk, but I have to say it 
does make it clear from a user perspective. 

I guess the ipkg approach would allow people to hold their PHP at a 
given minor release without changing the rest of OpenSolaris, but that's 
still at least a few months out.  :)  I don't know yet if it would mean, 
for instance, someone could install OpenSolaris 12/09 and get the PHP 
that was around back in 06/08.  If they could (even in an 'unsupported' 
fashion), then that would be a good thing since the monolithic approach 
we have right now would be broken up.

Presumably the opposite would be possible but I don't know.  Could I 
keep my OpenSolaris held back to 06/08 (if say, it weren't mine but I 
was just using shared infrastructure) and I wanted the 12/09 PHP?

I'm thinking about all of this in part because I just spent some time 
with a user who is stuck on PHP 4.2.3 because of an unfortunate bug in 
an extension, introduced in 4.3, that no subsequent release has fixed.  
I helped them to get 4.2.3 running on Solaris 10.

The bug was the kind of thing that you could ignore if you didn't rely 
on actually getting error handling with stored procedures.

- Matt

-- 
Matt Ingenthron - Web Infrastructure Solutions Architect
Sun Microsystems, Inc. - Global Systems Practice
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com Phone: 310-242-6439

-- next part --
An HTML attachment was scrubbed...
URL: 

[webstack-discuss] [dtrace-discuss] dtrace with php

[matt.ingenth...@sun.com]

Hi Michael,

Crossposting to webstack-discuss.  That list covers the group of 
packages which cover web functionality, like PHP. 

On 03/24/09 09:44, Michael Bonfils wrote:
> Hi,
>
> I test the dtrace plugin for php and there is only php_dtrace_execute that 
> seems to work, php_dtrace_execute_internal return nothing (and severals 
> examples from web show that it  show the php internal function, like 
> http://netevil.org/blog/2005/aug/dtracing-php-on-solaris )
>
> I'm using OpenSolaris 2008.11 with dev repository
>   
> May I have missing something ?
>   

Going in to the most recent releases, we've actually added some 
providers.  These should hit build 111, so I don't think they're there 
in 109 (assuming that's what you have), but I'm not sure when it went 
in.  It should give you quite a bit more functionality than was 
available previously, but the blogs from 2005(!) may no longer apply.

You can read about the new functionality here:
http://mail.opensolaris.org/pipermail/webstack-discuss/2009-February/002815.html

I think the best thing to to do would be to list what the php provider 
gives you, and then work from there.  I'm sure Sriram or others can help 
on the webstack-discuss list too.

- Matt

-- 
Matt Ingenthron 
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com

[webstack-discuss] memcache and mysql used together

[matt.ingenth...@sun.com]

Hi all,

I figured some people on this list may be interested in hearing about 
how these components can be used together, and are by Fotolog.

http://www.mysql.com/news-and-events/web-seminars/display-142.html

- Matt

-- 
Matt Ingenthron - Web Infrastructure Solutions Architect
Sun Microsystems, Inc. - Global Systems Practice
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com Phone: 310-242-6439

[webstack-discuss] Arc Case for obsolescence of some RubyGems interfaces

[matt.ingenth...@sun.com]

Hi all,


On 12/23/08 15:01, Jyri Virkki wrote:
> Amanda Waite wrote:
>   
>
>
>   
>
> It'd be nice to also document in the case itself what the new
> replacement for each of the obsoleted commands will be. Personally I
> won't require the case to cover that (the user docs will certainly
> have to cover it though, but you already mention that in s.2.4), it'd
> just be nice.  Maybe someone else might feel differently.
>   
This would be helpful for ARC, but I think what is in s 2.4 is great.

This is only loosely related, but did you see the mention of ruby in the 
ars-technica article (I meant to send this out a few weeks ago)?

"A major weak point for OpenSolaris is its limited support for
third-party software. There are some new applications included in
2008.11 and some new software in the system package repositories."
"Right now, most existing Linux users will probably have difficulty
adopting the platform because of the gaps in available software.
It's viability as a development platform will depend entirely on
what tools you are using for development. It ships with Python 2.4,
which is pretty stale by today's standards, but the main repository
provides enough Python library packages to facilitate basic PyGTK+
development (Update: Python 2.5 is available from the repository).
Its Ruby stack is very sparse and it lacks some basic components
such as IRB and the Ruby GTK+ bindings. The repositories are also
missing a bunch of other basic stuff that I require for development,
including GVim and Bazaar."

http://arstechnica.com/news.ars/post/20081204-hands-on-opensolaris-2008-11-a-major-step-forward-for-sun.html


It looks like we have irb, so I'm not sure what went wrong.  I suspect 
"ruby stack" may refer to other gems, but I don't know.  Perhaps we need 
to find a way to explain the philosophy of relying on gem somehow.

Has anyone emailed the author or looked into this?

- Matt

-- 
Matt Ingenthron 
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com

-- next part --
An HTML attachment was scrubbed...
URL: 

[webstack-discuss] Arc Case for obsolescence of some RubyGems interfaces

[matt.ingenth...@sun.com]

On 12/23/08 15:17, Matt.Ingenthron at Sun.COM wrote:
>
>
> 
> http://arstechnica.com/news.ars/post/20081204-hands-on-opensolaris-2008-11-a-major-step-forward-for-sun.html
>
>
> Has anyone emailed the author or looked into this?

Looking at the discussions, I see Prashant was on top of it.  I'm 
curious if the article author felt that addressed the question though... 
no luck in a reply posted.

- Matt

-- 
Matt Ingenthron 
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com

-- next part --
An HTML attachment was scrubbed...
URL: 

[webstack-discuss] Potential APC issue

[matt.ingenth...@sun.com]

Hi all,

A user ran into this problem in their Cool Stack deployment.  There may 
not be enough here to try to duplicate the issue, but the findings are 
certainly troubling.

- Matt

 Original Message 
Subject:[Cool Tools] APC caching issue on Coolstack 1.3
Date:   Mon, 27 Oct 2008 10:26:11 -0700
From:   Sun Developer Forums Watch 
To: Matt Ingenthron 



Matt Ingenthron,

You are watching the forum "Cool Tools", which was updated Oct 27, 2008 
10:26:06 AM by xander:


or


For your convenience, the new message is included below:
--
Hi,

We're trying out Cool Stack 1.3 on a Sun T5220 SPARC server, running a PHP 
based website. Everything is running on Solaris 10 under a zone.

We use mod_rewrite to redirect all requests (except static content, eg. css, 
images) to one of two PHP files depending on the URL. Ever so often we are 
finding that a certain URL is directed incorrectly to the other PHP file, 
originally we thought this was a mod_rewrite issue, but closer inspection shows 
that in fact APC is serving the incorrect file from its op-code cache.

Small tests have been placed at the top of each PHP file, to check that the 
file that is executed is actually the one Apache requests. Eg:

if (basename($_SERVER['SCRIPT_FILENAME']) != 'index.php')
error_log(...)

By looking at the error log, it can be seen that ever so often, the wrong 
script is executed.

We are also finding that this instance of APC doesn't seem to be caching every 
file, it simply misses some out (according to the bundled apc.php). Notably the 
two files mod_rewrite redirects to.

We have no idea what is causing this. We have an older Coolstack build running 
on an identical server (though not under a zone) which we have no problems with.

Any pointers would be much appreciated.

Kind regards,
Alex Forrow
--

To respond to this post, please click the following link:



-- 
Matt Ingenthron 
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com

-- next part --
An HTML attachment was scrubbed...
URL: 

[webstack-discuss] Unable to install 'amp' meta cluster

[matt.ingenth...@sun.com]

Sriram Natarajan wrote:
> Hi
>   I am running on indiana (opensolaris 2008.05 build 86 - with no 
> updates) and I am unable to get the following command working .
>
> [sriramn at sriramN]>pfexec pkg install amp
> pkg: no package matching 'amp' could be found in current catalog
>  suggest relaxing pattern, refreshing and/or examining catalogs
> pkg: install failed: Unable to assemble image plan
> [sriramn at sriramN]>
>
> Af course, it used to work fine earlier on my other machines. So, I am 
> wondering if some how recently released build 91 affects this. Is there 
> a log output or some thing that I can search to find the source of the error
>   

What does a pkg search -r say?  Also, you may want to run a pkg refresh 
first.

I've also learned (the hard way) that you should update your SUNWipkg 
pkg in many cases.  There are many changes to SUNWipkg even at the build 
86 level.  I don't think this is a cause for any of your issues, but 
it's still good to do.

- Matt

-- 
Matt Ingenthron - Web Infrastructure Solutions Architect
Sun Microsystems, Inc. - Global Systems Practice
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com Phone: 310-242-6439

[webstack-discuss] Start discussion on coexistence of two MySQL versions

[matt.ingenth...@sun.com]

Jyri Virkki wrote:
> Sunanda Menon wrote:
>   
>> How should these symbolic links  be  customarily  handled? 
>> 
>
> The 'latest' symlink maintenance is something everyone seems to be
> wondering about but nobody has looked into solving. I know Ruby team
> also needed something here and IIRC many others as well.
>   

There was also a lot of angst about the fact that it existed at all in 
several threads on SFWNV. It appears that it's initial introduction was 
with the JDK, and there were several people who thought it shouldn't 
have gotten through ARC.

On the other hand, there were others who thought it wasn't clean, but 
has worked out reasonably well. I'm probably on that side of the 
equation. By setting the path, you are in effect picking the stability 
level you're planning to work within (even if it, by definition, isn't 
stable).

> My suggestion is to take on this effort; maybe initially work with
> Prashant and webstack-discuss to come up with clearly laid out
> requirements. Then work with pkg-discuss community to look into
> solutions which meet those. Perhaps natively within IPS or as a
> reusable tool you could write. It'd be great to solve this for everyone.
>   

+1

It would be good to go look at the archives to be sure any issues which 
were brought up back then are pro-actively addressed.

- Matt

-- 
Matt Ingenthron - Web Infrastructure Architect
Sun Microsystems, Inc.
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com Phone: 310-242-6439

-- next part --
An HTML attachment was scrubbed...
URL: 

[webstack-discuss] quick question on mysql versions

[matt.ingenth...@sun.com]

Hi Jenny!

Luojia Chen wrote:
> Which version of opensolaris bundled with MySQL 5.0.45?
> What is the version of MySQL bundled with the latest opensolaris?
>   

One of the good things about IPS is that it will tell you what it's 
serving up just from any browser. Go to http://pkg.opensolaris.org and 
what's in the repository there is the latest.

Since build 93 is the latest developer build, it appears to be 
pkg:/SUNWmysql5 at 5.0.45,5.11-0.93:20080708T161250Z

I know this is being updated though, and there should be a change 
request targeting a release. It appears to be CR 6711903 and is 
targeting build 98.

Cool Stack is currently bundling 5.1.25.

Hope that helps,

- Matt

-- 
Matt Ingenthron - Web Infrastructure Architect
Sun Microsystems, Inc.
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com Phone: 310-242-6439

[webstack-discuss] Can we get a Mercurial repository for Memcached on opensolaris.org?

[matt.ingenth...@sun.com]

Hi Trond,

Unless there are any objections from anyone on the list, I think we can 
go ahead and set this up.  More inline below

Trond Norbye wrote:

(snip...)
>
> Our schedule is not 100% fixed yet, but one of the things we have in  
> our roadmap is to look into the scalability on multicore computers. We  
> will try to push our modifications upstream to the Memcached  
> community, but we need a place for the members of the team to store  
> our changes (and share with the team) before they are accepted into  
> the community version. This is also the version we are going to  
> integrate into Solaris.
>   

I think officially speaking, what is going into OpenSolaris would become 
part of the sfwnv consolidation like the rest of the Web Stack work.  
There are only a few high-level consolidations the work could become 
part of if it were to be part of OpenSolaris itself, instead of 
unbundled.  It's obviously not ON or Gnome/X11 or others. 

Having said that, I understand you need a place to work before putback 
to sfwnv and it'd be good to be able to easily get others on this list 
(and over in memcached) to see what all you're working on.  Longer term, 
if the sources end up being pretty much the same, and if the sfwnv 
consolidation gets to be more open, we may want to fold this in. 

The difficulty here is maintaining the history, but I don't want to get 
so stuck in analysis that we just don't do anything.

One other thing to consider here is issue tracking.  We can leverage the 
existing opensolaris.org stuff (warts and all) but should document it.  
What were your thoughts on that?  Is there an existing bugster category 
we should expose and then document on the project pages?

- Matt

-- 
Matt Ingenthron - Web Infrastructure Solutions Architect
Sun Microsystems, Inc. - Global Systems Practice
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com Phone: 310-242-6439

[webstack-discuss] webstack test report for nevada build79

[matt.ingenth...@sun.com]

Hi cvr,

I think you intended this for a different mailing list.

To fill folks in on webstack-discuss at opensolaris.org...
cvr is talking about moving some recent test result summaries to a wiki 
outside SWAN (sun's wide area network) from the wiki we've historically 
used for this sort of thing.

I'm sure we'll get another note when the test results are posted there. :)

- Matt

Murthy.Chintalapati at Sun.COM wrote:
> Makes sense. Perhaps post them to wikis.sun.com and have a link from the 
> web stack forum.
>
> David Van Couvering wrote:
>   
>> Note the QA results are within SWAN, perhaps we want to move these to
>> a location outside of SWAN?
>>
>> David
>>   
>> 
>
> ___
> webstack-discuss mailing list
> webstack-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
>   


-- 
Matt Ingenthron - Web Infrastructure Solutions Architect
Sun Microsystems, Inc. - Global Systems Practice
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com Phone: 310-242-6439

[webstack-discuss] FW: PHP with Apache in build 77

[matt.ingenth...@sun.com]

Hi,

I wanted to apologize for the delay in reply to this. More inline below...

UNIX admin wrote:
>> UNIX admin wrote:
>> 
>>> I'd like to start with making SUNW packages for
>>>   
>> PHP. Which steps
>> 
>>> must I take to formalize this?
>>>   
>> PHP (5.2.4) packages are already available, starting
>> from b76
>> (although b79 has the latest, including the MySQL &
>> Apache support, so
>> for experimenting, best to start with b79).
>>
>> We'll be updating it to 5.2.5 in the coming month or
>> so (and, I hope,
>> cleaning up the packaging a bit).
>> 
>
> I meant, I'd like to take ownership of / be responsible for delivering 
> SUNWphp* packages in OpenSolaris.
>
> Surely packaging is also something that can be offloaded "outside of the Sun 
> firewall"?
>   

Both of the lead engineers (Jyri Virkki and Arvind Srinivasan) who own 
this kind of work for the project are actually out on vacation. I too 
was out when these emails were posted, and I'm just now getting back to 
going through all of the old email. Many apologies!

I'm sure we'd welcome the help and Jyri/Arvind can probably figure out 
best to do that. Having said that, right now all of the package building 
is pretty tied to the SFWNV consolidation if you're talking about SysV 
packages.

For the OpenSolaris image packaging system, at least in the short term, 
I think we'll get that "for free" since the project Indiana folks are 
consuming all of the SUNW packages (including PHP) and translating them 
into ips format for the project indiana hosted repository.

I bet longer term there may be some changes to how we do that, but I 
don't think we've really thought that all the way through. Up until the 
end of December, the big push was to get all of the functionality 
reviewed and into build 79.

Whatever we end up with, that package coordination would need to be done 
with other components (like Apache). For instance, I'd discussed 
"clusters" like AMP or APP or AMR with the ipkg folks and they'd thought 
about it, but have had more pressing business to work on at the moment.

I'm sure Jyri or Arvind will be able to add more to the discussion when 
they return.

Again, sorry for the delayed response.

- Matt

-- 
Matt Ingenthron - Web Infrastructure Solutions Architect
Sun Microsystems, Inc. - Global Systems Practice
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com Phone: 310-242-6439

[webstack-discuss] who is using mysql on build 79 or later?

[matt.ingenth...@sun.com]

Hi Neal!

Neal Pollack wrote:
> Mysql5 will not run on my Neveda build 79 system.
> Not sure where customers are supposed to find out
> about how to get it running?
>   

In the "Developer Tools" menu there are some scripts that assist with 
setting up mysql5.  There's still some work to be done (and some bugs 
filed, notably CR 6641919, fixed in 79a) to help with some of the other 
issues.  In fact, I filed one just the other day related to the mysql 
service.

You can see the design intent for the developer experience on the Web 
Stack project wiki:
http://wikis.sun.com/display/WebStack/WebStack+setup+before+B79

There you'll see screenshots of what I mean.

We know there's more refining to do, but got something put together for 
79a.  Please send over any feedback.

Of course, build 79 isn't available outside Sun yet (darn lawyers!), but 
everyone should be able to play with this very soon with build 79a.

> I tried to start mysql5 using svcadm enable.
> Not sure if there is a getting started doc, but I basically found dir
> /usr/mysql/5.0/bin and executed mysql_install_db from there.
> That created the mysql dir and files under /var/mysql/5.0/data/
>
> However;
> # svcs -x
> svc:/application/database/mysql:version_50 (MySQL RDBMS)
> State: maintenance since January 16, 2008  6:48:05 PM PST
> Reason: Start method exited with $SMF_EXIT_ERR_CONFIG.
>   See: http://sun.com/msg/SMF-8000-KS
>   See: MySQL 5.0.45(1)
>   See: http://dev.mysql.com/docs
>   See: /var/svc/log/application-database-mysql:version_50.log
> Impact: This service is not running.
> zbit:/var/mysql/5.0# cat 
> /var/svc/log/application-database-mysql:version_50.log
> [ Dec  5 17:53:22 Disabled. ]
> [ Dec  5 17:53:22 Rereading configuration. ]
> [ Jan 16 18:48:05 Enabled. ]
> [ Jan 16 18:48:05 Executing start method ("/lib/svc/method/mysql start"). ]
> mysql/data directory /var/mysql/5.0/data is not a valid MySQL data 
> directory <<<=== ***
> [ Jan 16 18:48:05 Method "start" exited with status 96. ]
>
>
> So I notice that the data dir, and all files in it are owned by root.
> is that correct?
> I did try a chown -R mysql:mysql in that dir to see if it helps, but I get
> the same error while trying to start mysqld.
>
> What am I overlooking, and where is the doc for the proper way
> to configure and start mysql specific to our Solaris layout?
>
> Thanks,
>
> Neal
>
>
>
> ___
> webstack-discuss mailing list
> webstack-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
>   


-- 
Matt Ingenthron - Web Infrastructure Solutions Architect
Sun Microsystems, Inc. - Global Systems Practice
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com Phone: 310-242-6439

[webstack-discuss] Review request - MySQL 64bit and Connectors ARC case

[matt.ingenth...@sun.com]

Peter Tribble wrote:
> If you have an x64 system then running in 64-bit is clearly the
> right choice, so isaexec would work fine and would probably
> be the right choice there.
>
> It might be useful to do a comparison on sparc. But my general
> experience there is that 64-bit isn't generally better and is only
> usually worth it if you need the extra addressability.
>
>   

My concern, in this particular case, wasn't so much with the performance 
of the binaries (though that is certainly important!), but rather with 
what would yield the most working configurations OOB.

These days, PHP, Apache, Perl, Ruby and Python all assume there is a 
compiler laying around that is compatible with the rest of the system 
for building extensions.  At least a couple of the above leave build 
flags hanging out in configuration files, so when you "gem" or "pecl" or 
"apxs" something, they'll make an attempt to build/integrate it for you.

Some of these extensions may not be 64-bit clean.  A lot of this stuff 
has been cleaned up in the past three-to-four years (as 64-bit became 
more the norm), but I'm sure not all of it has.  I don't know how much 
though.

What would concern me is the guy evaluating OpenSolaris, grabbing an 
extension that's needed for his application, running 
gem/apxs/phpize/pecl and then seeing it blow up.   The install readme 
won't likely have an "if you're on OpenSolaris" branch, and it may not 
even be clear where the problem is.  The quick conclusion someone could 
come to in that case is that Web Stack is broken...  not what we want.

- Matt

-- 
Matt Ingenthron - Web Infrastructure Solutions Architect
Sun Microsystems, Inc. - Global Systems Practice
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com Phone: 310-242-6439

[webstack-discuss] Review request - MySQL 64bit and Connectors ARC case

[matt.ingenth...@sun.com]

Jyri Virkki wrote:
> Matt Ingenthron wrote:
>   
>> I believe we'll need to deliver both, and there are probably still a 
>> number of reasons (for now) that one may choose to run 32-bit even on a 
>> system with a 64-bit ISA, which means there has to be a switch somewhere 
>> to pick what one wants to run.
>> 
>
> As you say, I doubt 64bit is universally always the right answer for
> every conceivable scenario, so there needs to be some sort of switch.
>
> So the question becomes what should be the out-of-box default. Barring
> compelling arguments otherwise, I'll always argue for consistency
> (which seems to be the direction the proposal is going).
>
> Peter mentioned better performance on x86 which may well be a
> compelling argument depending on the details. The db team should
> research this so there's enough data to declare it one way or the
> other.
>   

Agreed, and I apologize for hijacking this thread into a general 
32/64-bit concern in my last email.  We should have some data to work 
with, and from history with MySQL, I think this is available/easy to 
obtain.  Anything that is usually deployed in a read-mostly fashion and 
can have a large memory cache is pretty easy to make an argument for.

Regarding consistency though, it could be entirely appropriate for MySQL 
to default to 64-bit on capable platforms, while other parts of the 
stack deliver in 32-bit by default as they currently do, right? 

This is predicated on having data on which to base this decision though.

- Matt

-- 
Matt Ingenthron - Web Infrastructure Solutions Architect
Sun Microsystems, Inc. - Global Systems Practice
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com Phone: 310-242-6439

[webstack-discuss] MySQL University Sessions

[matt.ingenth...@sun.com]

MySQL has various "University" sessions where they cover topics on MySQL 
futurues and technologies related to MySQL.  A couple of the requested 
ones are related to Solaris, and several of them are related to how 
MySQL can be used with other tools/languages.

http://forge.mysql.com/wiki/MySQL_University

Ludo: perhaps they'd be interested in a session on NB6/Web Stack?

DB team: perhaps they'd welcome some collaboration on the Solaris 
related topics?

Just a thought...

- Matt

-- 
Matt Ingenthron - Web Infrastructure Solutions Architect
Sun Microsystems, Inc. - Global Systems Practice
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com Phone: 310-242-6439

[webstack-discuss] [databases-discuss] Review request - MySQL 64bit and Connectors ARC case

[matt.ingenth...@sun.com]

Martin MC Brown wrote:
> Hi,
>
 This is predicated on having data on which to base this decision 
 though.

>>>
>>>
>>> If somebody wants me to do any necessary tests with the various 
>>> MySQL versions and SPARC/intel combinations with 32bit/64bit let me 
>>> know.
>>>
>> Yes, if you have any chance of doing that, it would be great!
>
>
> OK, here are the headline results for x86. Tests were doing using 
> MySQL 5.0.56 (which I happen to be smoke testing at the moment), on 
> the same machine, running snv_81.

Thanks! Quite useful.

Could you share any details on the build. Which compiler did you use, 
any optimization flags, etc.? It would be useful to have that info.
>
> Results are using the included sql-bench, standard tests (InnoDB not 
> included):
>
> Using 32-bit packages:
>
> alter-table: Total time: 18 wallclock secs ( 0.05 usr 0.04 sys + 0.00 
> cusr 0.00 csys = 0.09 CPU)
> ATIS: Total time: 20 wallclock secs ( 2.94 usr 0.40 sys + 0.00 cusr 
> 0.00 csys = 3.34 CPU)
> big-tables: Total time: 14 wallclock secs ( 3.43 usr 0.25 sys + 0.00 
> cusr 0.00 csys = 3.68 CPU)
> connect: Total time: 134 wallclock secs (29.68 usr 23.16 sys + 0.00 
> cusr 0.00 csys = 52.84 CPU)
> create: Total time: 348 wallclock secs ( 2.87 usr 1.88 sys + 0.00 cusr 
> 0.00 csys = 4.75 CPU)
> insert: Total time: 1038 wallclock secs (217.49 usr 77.17 sys + 0.00 
> cusr 0.00 csys = 294.66 CPU)
> select: Total time: 399 wallclock secs (19.76 usr 4.95 sys + 0.00 cusr 
> 0.00 csys = 24.71 CPU)
> transactions: Test skipped because the database doesn't support 
> transactions
> wisconsin: Total time: 10 wallclock secs ( 1.70 usr 0.95 sys + 0.00 
> cusr 0.00 csys = 2.65 CPU)
>
> Using 64-bit packages:
>
> alter-table: Total time: 15 wallclock secs ( 0.05 usr 0.04 sys + 0.00 
> cusr 0.00 csys = 0.09 CPU)
> ATIS: Total time: 17 wallclock secs ( 2.95 usr 0.42 sys + 0.00 cusr 
> 0.00 csys = 3.37 CPU)
> big-tables: Total time: 11 wallclock secs ( 3.43 usr 0.23 sys + 0.00 
> cusr 0.00 csys = 3.66 CPU)
> connect: Total time: 121 wallclock secs (29.69 usr 24.75 sys + 0.00 
> cusr 0.00 csys = 54.44 CPU)
> create: Total time: 348 wallclock secs ( 2.87 usr 1.94 sys + 0.00 cusr 
> 0.00 csys = 4.81 CPU)
> insert: Total time: 885 wallclock secs (215.78 usr 74.40 sys + 0.00 
> cusr 0.00 csys = 290.18 CPU)
> select: Total time: 257 wallclock secs (19.59 usr 5.06 sys + 0.00 cusr 
> 0.00 csys = 24.65 CPU)
> transactions: Test skipped because the database doesn't support 
> transactions
> wisconsin: Total time: 8 wallclock secs ( 1.67 usr 0.93 sys + 0.00 
> cusr 0.00 csys = 2.60 CPU)
>
> This shows a moderate increase in speed for insert (15%) and select 
> (35%), and smaller increases for some other tests.
>
> I'll be doing longer testing of this over the weekend to see if I can 
> repeat this level of increase over a larger number of iterations.
>
> SPARC is showing similar output, but I had an unrelated problem with 
> the box I was running the tests on so I've had to restart.
>
> I'll also be running dbt2 tests, where I expect to get pretty similar 
> increase numbers.
>
> MC
>
> -- 
> Martin 'MC' Brown, mc at mcslp.com
> Everything MCslp: http://planet.mcslp.com
>
>


-- 
Matt Ingenthron - Web Infrastructure Solutions Architect
Sun Microsystems, Inc. - Global Systems Practice
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com Phone: 310-242-6439

[webstack-discuss] [sfwnv-discuss] resend: need Code Review for Lighttpd 1.4 integration

[matt.ingenth...@sun.com]

Jyri Virkki wrote:
> *** usr/src/cmd/lighttpd14/Solaris/index.html
> - Please don't deliver a default index.html file. Unfortunately this isn't
>   set up yet (and unclear when it will be) but the intent is to move these
>   default index files to a distro-specific package so they can carry the
>   name/logo/etc of the distro.  Delivering the index.html file now and
>   later having to make this package not be its owner is more hassle
>   which you could avoid.
>   
>

On this item, with this integration could we define/deliver a package 
for the lighttpd default content? Perhaps something like 
SUNWlighttpd14u-content upon which SUNWlighttpd14u depends?

I know we want the later flexibility, but delivering a webserver which 
issues 404s when you first turn it on and make a request is also not good.

- Matt

-- 
Matt Ingenthron - Web Infrastructure Solutions Architect
Sun Microsystems, Inc. - Global Systems Practice
http://blogs.sun.com/mingenthron/
email: matt.ingenthron at sun.com Phone: 310-242-6439